The present invention is a method and apparatus for virtualizing file access operations and other I/O operations in operating systems. More specifically, the present invention virtualizes file access operations and other I/O operations by performing string substitutions upon file paths or other resource identifiers to convert the virtual destination of an operation to a physical destination.
In the art of computing, an operating system is typically used to provide access to the resources of a computer system. One important type of resource that must be accessed is the file system. Typically, a file system provides access to files on a local hard drive, as well as files that may reside on a network server, which is coupled to the computer system via a network.
One trend that has been important to the evolution of computing is to virtualize resources, thereby provided a computer program with a virtualized version of a resource and making the actual (or physical) attributes of a resource invisible to the program. For example, virtual memory systems, which are well known in the art, provide a computer program with the illusion that the program can access a large contiguous area of memory, which is known in the art as virtual memory. The operating system manages translations between virtual memory and physical memory. Contiguous regions of virtual memory may be mapped to non-contiguous regions of physical memory, and portions of virtual memory may be stored in a swap file on a hard disk drive of the computer system. This allows the computer system to execute programs requiring more memory than is physically available in the computer system, and allows multiple programs to be active simultaneously. Other examples of virtualized resources include multiple CPUs, and multiple windows in a windowed operating system.
Despite the trend toward virtualizing computer system resources, file systems tend to have very limited virtualization features. Typically, once the physical location of a hard drive, and the directory structure and files contain thereon, has been defined, a computer program is locked into this structure. For example, consider a simple example faced by many computer users using the Windows NT(copyright) or Windows(copyright) 98 operating system, which are products of Microsoft(copyright) Corporation. A computer user purchases a computer system with a single hard drive that is referenced as xe2x80x9cc: xe2x80x9d. Over time, the user fills up the hard drive, and therefore adds a second hard drive that will typically be referenced as xe2x80x9cd: xe2x80x9d. To recover space on the original xe2x80x9cc: xe2x80x9d drive, the user may wish, for example, to move the contents of the directory xe2x80x9cc: Program Filesxe2x80x9d to xe2x80x9cd: Program Filesxe2x80x9d. However, doing so causes many problems. For example, all the shortcuts for accessing programs from the start menu still refer to the xe2x80x9cc: xe2x80x9d drive, so the user will no longer be able to launch the programs. Furthermore, the registry contains numerous references to the programs that were previously stored on the xe2x80x9cc: xe2x80x9d drive. Typically, the user must reinstall all the applications that are to be moved to the xe2x80x9cd: xe2x80x9d drive, or purchase and execute a third party utility that attempts to find every reference to the moved applications in shortcuts, the registry, or any other place where a reference may be located, and alter those references. Both processes are cumbersome, and may not be completely effective.
There are a number of mechanisms known in the art that can virtualize file system access operations to a limited extent. For example, in the Windows NT(copyright) or Windows(copyright) 98 operating system, a global variable called xe2x80x9cTempxe2x80x9d is typically defined that allows all programs to access a common temporary directory. By changing the file path contained in the variable, the location of the temporary directory used by all programs can also be changed.
Two other mechanisms common in Unix(copyright) operating systems are symbolic links and hard links. Unix(copyright) is a trademark of the Open Group. In the Unix(copyright) operating system, each file and directory location is defined by an xe2x80x9cionodexe2x80x9d number, and the file system directory maintains mappings between file and directory names and ionode numbers. A hard link is simply a second mapping between a file or directory name and an ionode number that has already been mapped to a first name. The file or directory is not actually deleted until all file and directory names that map to the ionode number have been deleted. Hard links must reference files and directories on the same file system, are transparent to the application, and cannot be used to arbitrarily re-map between partitions or devices because the ionode numbers only refer to files and directories within the file system.
In contrast, a symbolic link is a separate file with its own ionode number. The symbolic link contains a text string that points to another file or directory. Accordingly, symbolic links can be used to reference files and directories in different file systems. Symbolic links are not transparent to the application, since the application can detect that it is accessing a link and not the actual file or directory. Furthermore, deleting a symbolic link deletes the link, not the file or directory. Like hard links, symbolic links translate a single file or directory from one location to another. However, symbolic links may be arbitrarily re-mapped from one file system to another.
Mount points can also virtualize file systems to some extent. Amount point simply allows a drive volume to be mounted at some point within an existing directory tree structure. For example, assume that a hard drive on a file sever has a root directory, and under the root directory are a series of directories, with each directory identified by the initials of the user that uses that directory. When a user logs in, a drive volume is mounted at the directory corresponding to the users initials. When the user accesses that drive volume, the user only sees directories and files beneath the mounting point, and does not see the directories of the other users. Mount points are transparent to applications and can be re-mapped arbitrarily, but do not provide file level granularity and do not re-map directories underneath the mount point.
Finally, some enterprise storage subsystems have the ability to move a user""s file system from one hard drive to another. Such moves can be performed arbitrarily and are transparent to applications, but do not provide file or directory level granularity.
Taken individually, none of these mechanisms provides a means to arbitrarily re-map files and directories at any level and between any file system in a manner that is transparent to applications. In essence, none of these mechanisms is capable of providing applications with a xe2x80x9cvirtual viewxe2x80x9d of the file system. What is needed in the art is a mechanism that can arbitrarily re-map files and directories at any level and between any file system in a manner that is transparent to applications. In essence, what is needed in the art is a mechanism capable of completely virtualizing an application""s view of the file system, just as a virtual memory system virtualizes an application""s view of a physical memory system.
The present invention provides a method and apparatus for virtualizing file access operations and other I/O operations in operating systems by performing string substitutions upon a file paths or other resource identifiers to convert the virtual destination of an I/O operation to a physical destination. In accordance with the present invention, a virtual file system translation driver is interposed between a file system driver and applications and system utilities. The virtual file system translation driver receives file access requests from the applications and system utilities, and translates the file path to virtualize the file system. The virtual file system translation driver can also be combined with the file system driver to create a combined virtual file system driver. The present invention can be utilized on workstations, network servers, and other computing devices.
In a first embodiment of the invention, the file system is partially virtualized and a user can see both the virtual file paths and the physical file paths. In this embodiment, the virtual file path is translated to a physical file path if a translation exists, and the file access operation is processed using the physical file path. If no translation exists, the file path provided by the application or utility is used to process the file access request.
In second and third embodiments of the present invention, the file system is completely virtualized from the point of view of the applications and system utilities. In the second embodiment, a user may start with a physical file system, and virtualize the file system by installing the virtual file system translation driver. When the driver is initially installed, all virtual file paths will be considered to translate to identically named physical file paths by default. In the third embodiment, virtual translations are automatically generated for all file paths when files and directories are created, and virtual file paths may bear limited, or no resemblance to physical file paths.
One of the disadvantages provided by prior art file system is that the attributes of a particular storage device apply globally to all files in the file system. In essence, the attributes of the storage device are xe2x80x9cjoined at the hipxe2x80x9d with the file system installed on the storage device. The present invention breaks this connection. Accordingly, a user can view a single file system, yet files within that file system can be stored on storage devices having different attributes. The present invention provides many other advantages and may be implemented in several ways, as described in greater detail below.